home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
lists
/
mint
/
l_0399
/
81
< prev
next >
Wrap
Internet Message Format
|
1994-08-27
|
2KB
From: bammi@Cadence.COM (jwahar r. bammi)
From: bammi@cadence.com (jwahar r. bammi)
Date: Thu, 11 Feb 93 22:30:02 EST
Date: Thu, 11 Feb 93 22:18:29 EST
Subject: RE: Fcntl's
Subject: RE: Fcntl's
Date: Thu, 11 Feb 93 22:30:02 EST
Message-Id: <9302120330.AA01545@acae127.cadence.com>
From: bammi@Cadence.COM (jwahar r. bammi)
X-Organization: Cadence Design Systems
To: mint@atari.archive.umich.edu
Subject: RE: Fcntl's
Forwarded-From: bammi@cadence.com
---------------------- FORWARDED MESSAGE FOLLOWS -----------------------
Date: Thu, 11 Feb 93 22:18:29 EST
From: bammi@cadence.com (jwahar r. bammi)
X-Organization: Cadence Design Systems
To: uunet!netcom.com!ersmith
In-Reply-To: Eric R. Smith's message of Thu, 11 Feb 93 14:18:50 -0800 <9302112218.AA11425@netcom.netcom.com>
Subject: RE: Fcntl's
> (1) FUTIME seems like a good idea to me.
to me too.
>
> (2) Having a way to tell file systems how big a file could become (like
> a "maximum" file size) would be very useful for implementing contiguous
> files. So this also sounds like a good idea.
sorry cant agree with this one. its much more optimal to
concentrate on either trying to do blocks intelligently (bsd ffs
maybe) or like the upcoming extents FS for bsd 4.4 (see this winters
usenix proceeding for some good stats, and how it fared against
sprites log file system). only in a limited number of situations can
the file size be prdicted, that too mostly at creation. a file is
hopefully is modified (or replaced) a lot more times, than it is
created. if file contiguity is a big concern, i would venture to say
that a defragger is an appropriate tool. (btw dave evans has updated
his old toolkit (marketed by michtron at one time) to handle large
partitions etc.it works great!).
cheers,
--
bang: uunet!cadence!bammi jwahar r. bammi
domain: bammi@cadence.com
GEnie: J.Bammi
CIS: 71515,155